> **Source of truth for:** beginner-facing agentic coding manual, workflow lessons, common confusion points, and aligned free learning resources. > **Last updated:** 2026-06-02 # Agentic Coding Starter Manual This manual is for people who want to build real projects with AI agents without turning the chat into a pile of forgotten decisions, broken files, and half-finished ideas. The core lesson from this product build is simple: agentic coding is not mostly about one perfect prompt. It is about giving the agent durable context, clear rules, a small next task, and a verification loop. The agent can move fast. The human has to keep it pointed at value. ## Quick Index - [Start Here](#start-here) - [If You Are Overwhelmed](#if-you-are-overwhelmed) - [Learning Outcomes](#learning-outcomes) - [The Mental Model](#the-mental-model) - [Questions A Smart Beginner Will Ask](#questions-a-smart-beginner-will-ask) - [The Basic Workflow Loop](#the-basic-workflow-loop) - [Common Questions New Agentic Coders Ask](#common-questions-new-agentic-coders-ask) - [Common Failure Modes](#common-failure-modes) - [What To Ask The Agent](#what-to-ask-the-agent) - [What The Human Still Owns](#what-the-human-still-owns) - [Project Memory Files](#project-memory-files) - [Version Control And Backups](#version-control-and-backups) - [Testing And Verification](#testing-and-verification) - [Scope Control](#scope-control) - [When To Build, Park, Or Delete An Idea](#when-to-build-park-or-delete-an-idea) - [Working With Accounts, Payments, And Private Data](#working-with-accounts-payments-and-private-data) - [From Activist Angle To Action](#from-activist-angle-to-action) - [Free Learning Resources](#free-learning-resources) - [Glossary](#glossary) - [Checklists](#checklists) ## Start Here ### TLDR If someone is new to agentic coding, give them this operating rule: 1. Put the project memory in files, not only in the chat. 2. Ask the agent to inspect the folder before it edits. 3. Keep one clear "Now" task. 4. Make the agent explain risks before building. 5. Verify the result before adding the next feature. 6. Use Git or another backup habit before risky changes. 7. Do not confuse more output with progress. The best agentic coders are not the people with the fanciest prompts. They are the people who keep the work structured enough that the agent can help without taking over the direction. ## If You Are Overwhelmed ### TLDR Do not read this whole manual first. Use this section, start a tiny project, and come back when a question appears. If the manual feels like a lot, do this: 1. Create a folder for one small project. 2. Create one file called `PROJECT_STATE.md`. 3. Write three lines: what you are building, who it is for, and what the next useful result is. 4. Ask the agent to inspect the folder before changing anything. 5. Ask for one next task, not the whole project. 6. After the task, ask what needs to be tested. First learning outcome: the user should feel, "I know how to restart tomorrow without explaining everything again." ## Learning Outcomes ### TLDR The manual should leave the reader with practical habits, not only inspiration. After using this manual, a new agentic coder should be able to: - Explain what an AI agent is and is not. - Start a project with durable file-based memory. - Ask the agent to inspect before editing. - Separate current work from parked ideas. - Use a simple verification checklist. - Know which tasks belong to the agent and which belong to the human. - Use Git or backups before risky changes. - Decide whether an idea is v1, v2, parked, or out of scope. - Find free learning resources without getting trapped in platform hype. ## The DigitalQuill Trinity ### TLDR Use three questions to keep agentic coding useful instead of chaotic: 1. **Outcome:** are we shipping a useful, testable result? 2. **Agency:** does this make the human clearer, safer, more capable, or more in control? 3. **AI Hygiene:** did the agent handle context, scope, privacy, verification, tools, and cost responsibly? DigitalQuill uses this trinity because each lens catches a different failure mode. Agile practice catches drift and unfinished work. The Popsicle Index catches work that looks productive but does not make life better. AI best practices catch unsafe autonomy, weak verification, messy context, and overreliance on the model. Before adding a feature, ask: 1. What working outcome will this produce? 2. How will this help the human make a better decision or finish something real? 3. What needs to be verified, protected, or kept out of context? If one answer is weak, the next task is not "add more." The next task is to fix the weak side. ## The Mental Model ### TLDR The agent is a fast helper. The project needs files. The human stays responsible for direction, judgment, and final verification. ### An Agent Is A Worker, Not The Project An AI agent is a capable assistant that can read context, make plans, edit files, run tools, and report results. It is not the project owner. It does not automatically know what matters. It does not automatically know what should wait. The human owns: - The goal. - The value judgment. - The final decision. - The testing that requires human taste, credentials, payment settings, or real device behavior. The agent owns: - Reading the available context. - Turning vague goals into concrete options. - Implementing scoped tasks. - Testing what can be tested with tools. - Explaining risks and tradeoffs. - Updating project memory. ### The Chat Is Not Enough Chats are temporary working space. Project memory should live in files that can be reopened, read by another agent, backed up, searched, and inspected by a human. At minimum, every serious agentic project needs: - `PROJECT_STATE.md`: current goal, blocker, status, and what is solid. - `TODO.md`: what is active, next, later, and out of scope. - `DECISIONS.md`: locked decisions and why they were made. - `ITERATION_LOG.md`: dated history of what changed. - `PENDING_VERIFICATION.md`: work that looks complete but still needs proof. - `TEST_CHECKLIST.md`: the actual verification path. This is the difference between "the agent remembers" and "the project remembers." ## Questions A Smart Beginner Will Ask ### TLDR Smart beginners do not need hype. They need honest answers about what to learn, what to trust, and where the boundaries are. ### "Do I need to know how to code?" Not at first, but basic literacy helps quickly. A new builder does not need to write every line by hand, but they should learn enough to recognize file types, run simple commands, read error messages, and understand what changed. Practical target: learn enough HTML/CSS/JavaScript or Python to follow the shape of the work. The agent can fill in details, but the human should understand the project at the level of "what file owns what behavior?" ### "Which AI agent should I use?" Use the one that fits the work and your budget, but do not make the agent the center of the workflow. The project memory should be portable. If the files are clear, a future model or different tool can pick up the work. ### "How much should I trust the agent?" Trust the agent to help. Do not trust unverified output. If the agent changes files, ask what changed. If the agent claims a feature works, ask how it tested that claim. ### "What should I learn first?" Learn in this order: 1. Markdown, because project memory lives in plain text. 2. Git basics, because agentic coding needs checkpoints. 3. The minimum web or app stack for the project. 4. Prompting habits for the agent you use. 5. Safety and privacy basics. ### "What if I am technical but new to agentic coding?" The trap for technical users is assuming normal software discipline is optional because the agent is fast. It is not. Git, tests, scope control, small diffs, and clear ownership matter more when the agent can change many files quickly. ### "What if I am non-technical?" The trap for non-technical users is treating the agent like a magic builder. It is better to treat the agent like a patient contractor: explain the goal, keep written decisions, ask what it changed, test the result, and make the next call. ## The Basic Workflow Loop ### TLDR The loop is: orient, choose one task, check risks, implement narrowly, verify, record. Repeat. ### 1. Orient Before editing, ask the agent to inspect the folder and summarize what it found. Good prompt: ```text Explore this folder first. Tell me the project structure, what looks active, what looks risky, and what files you need to read before changing anything. ``` Why it works: the agent stops guessing and starts from the real project. ### 2. Choose One Next Task Agentic coding gets messy when every idea becomes active. Keep a single "Now" task. Good prompt: ```text Based on the current project files, what is the highest-value next task, what should wait, and why? ``` ### 3. Ask For Risks Before Work The agent should not only say how it will build the feature. It should say what can break. Good prompt: ```text Before implementing, list the likely failure modes and the smallest safe implementation path. ``` ### 4. Implement Narrowly Small changes are easier to verify. They also make it easier to understand what went wrong when something breaks. Good prompt: ```text Implement only the smallest useful version of this. Do not refactor unrelated files. ``` ### 5. Verify A feature is not done because the agent says it is done. It is done when the expected behavior is observed or the remaining gap is recorded. Good prompt: ```text Test the changed behavior, report what passed, what failed, and what still needs my human verification. ``` ### 6. Record When the task is complete, update project memory. Good prompt: ```text Update the project state, TODO, pending verification, and iteration log so the next agent can pick up cleanly. ``` ## Common Questions New Agentic Coders Ask ### TLDR Most repeated questions are not really about prompts. They are signs that memory, scope, verification, or responsibility boundaries need to be clearer. ### "Can you pick up where we left off?" What it really means: the project needs durable memory. Better pattern: point the agent at `PROJECT_STATE.md`, `TODO.md`, `DECISIONS.md`, and `ITERATION_LOG.md`. If those files do not exist, create them. ### "Why did this file or website get touched?" What it really means: scope boundaries were unclear. Better pattern: require the agent to name the files it plans to touch before editing. After the edit, ask for a file-by-file change summary. ### "Did we ever implement that feature?" What it really means: the project has ideas, active work, parked work, and completed work mixed together. Better pattern: maintain a clear state vocabulary: - **Active:** being built or verified now. - **Next:** likely soon, but not currently being edited. - **Parked:** useful idea, deliberately not being built yet. - **Done:** implemented and verified. - **Review:** implemented but waiting for proof. - **Out of scope:** not part of this release. ### "Should we build this now?" What it really means: the idea might be valuable but badly timed. Better pattern: ask the agent to rate the idea against the current sprint goal, user value, complexity, and release risk. ### "How confident are we?" What it really means: the project needs evidence, not vibes. Better pattern: confidence should be based on: - Syntax/build checks. - Browser or runtime tests. - Real-folder checks. - Manual user verification. - Known gaps listed in `PENDING_VERIFICATION.md`. ### "Can the agent set up my account/payment/platform?" What it really means: some work crosses into credentials, payments, or private settings. Better pattern: let the agent prepare copy, checklist, and configuration guidance. The human should handle sensitive account actions directly. ### "Why does the dashboard/app work in demo but not with my real files?" What it really means: demo data is not a full substitute for real-folder behavior. Better pattern: keep separate test paths: - Demo smoke test. - Real-folder test. - Mobile/desktop viewport test. - Human credential/account test. ## Common Failure Modes ### TLDR Agentic coding usually fails from drift, not incompetence: unclear memory, too much scope, weak verification, parallel edits, and V2 ideas sneaking into V1. ### 1. Chat Memory Replaces Project Memory Symptom: every session starts with "let me remind you what we built." Fix: create project files and make the agent read them first. ### 2. Building Runs Ahead Of The Backlog Symptom: many features exist, but nobody can say what release is trying to prove. Fix: use a backlog with priorities. Decide what is v1, v2, parked, and out of scope. ### 3. Verification Debt Piles Up Symptom: features are "code-complete" but not trusted. Fix: keep `PENDING_VERIFICATION.md`. Stop adding features when too much is waiting for proof. ### 4. The Agent Writes Too Much At Once Symptom: large files break, get truncated, or become hard to review. Fix: split large files into smaller modules. Prefer external JavaScript/CSS over giant single-file dashboards when edits become risky. ### 5. Multiple Agents Edit The Same Files Symptom: work collides, files drift, and nobody knows which copy is current. Fix: one writer per file at a time. Use branches or separate work lanes for parallel experiments. ### 6. Browser Limits Are Mistaken For Product Bugs Symptom: the agent says it cannot test a file picker, open a payment setting, or run a local command from the browser. Fix: separate browser-safe behavior from native app behavior. Some things require the human, a terminal, or a desktop app wrapper. ### 7. V2 Ideas Sneak Into V1 Symptom: a simple release becomes sync, enterprise, telemetry, dashboards, payments, branding, and advanced analytics all at once. Fix: keep a release rule: v1 proves the core value. V2 expands only after repeated user pain. ### 8. The Human Stops Challenging The Agent Symptom: the agent agrees, builds, and adds complexity without pushback. Fix: ask for critique: ```text Challenge this idea. What is the simplest reason not to build it yet? ``` ## What To Ask The Agent ### TLDR Ask for orientation, tradeoffs, smallest safe implementation, verification, and what still needs the human. Do not only ask for output. ### Good Discovery Prompts ```text Explore the folder first. What is the project, what is active, what looks stale, and what should not be touched? ``` ```text Read the project memory files and tell me the current sprint goal, blocker, and next best task. ``` ### Good Planning Prompts ```text Give me the smallest release-safe plan. Separate v1, v2, parked, and out-of-scope. ``` ```text What would increase confidence in this project the most? ``` ### Good Implementation Prompts ```text Implement the smallest useful version. Preserve existing patterns. Do not rewrite unrelated files. ``` ```text If you see anything funny while doing this, note it and fix only what is clearly related or low-risk. ``` ### Good Verification Prompts ```text Run the checks you can run. Then tell me exactly what still needs my human test. ``` ```text Use a code-review stance. Lead with bugs, risks, regressions, and missing tests. ``` ### Good Strategy Prompts ```text Is this a v1 feature, v2 feature, parked idea, or out-of-scope idea? Explain the tradeoff. ``` ```text Would adding this help buyers trust the product, or would it make onboarding harder? ``` ## What The Human Still Owns ### TLDR The agent can do a lot of work, but the human owns taste, ethics, accounts, private data, business judgment, and whether the result is actually useful. Even with a strong agent, the human still has work. ### Taste The agent can implement a design, but the human decides whether the design feels right for the audience. ### Business Judgment The agent can explain tradeoffs. It cannot know what risk is worth taking for the business. ### Sensitive Accounts The agent can draft Gumroad copy, Cloudflare setup notes, or payment instructions. The human should handle payment methods, credentials, and final account settings. ### Real-World Verification The agent can run automated tests. The human still needs to confirm: - Device feel. - Login/account flows. - Payment setup. - Native file picker permissions. - Whether the product makes sense to a real buyer. ### Final Responsibility If the project ships, the human ships it. The agent helped. It did not become accountable. ## Project Memory Files ### TLDR Memory files make the project portable across chats, agents, and time. They are the foundation of serious agentic coding. ### Minimum File Set Use this set for any serious project: | File | Purpose | |---|---| | `PROJECT_STATE.md` | Current truth: phase, goal, blocker, what's solid, what's pending. | | `TODO.md` | Active work, next work, later work, out of scope. | | `DECISIONS.md` | Accepted decisions and revisit triggers. | | `ITERATION_LOG.md` | Dated history. Append-only. | | `PENDING_VERIFICATION.md` | Code-complete but not yet proven work. | | `TEST_CHECKLIST.md` | What must be tested before calling work done. | | `RISK_POLICY.md` | What needs caution, approval, or stop conditions. | ### Optional But Valuable | File | Use when | |---|---| | `VALUE_LEDGER.md` | You need to rank features by value, not excitement. | | `WORKFLOW_MAP.md` | You need to understand the user's journey through the product. | | `TOOL_RECOMMENDATIONS.md` | You want the agent to suggest tools without adding them blindly. | | `CONTEXT_HEALTH.md` | You are fighting context bloat or expensive sessions. | | `TECHNICAL_PRODUCT_MANUAL.md` | You need a deep handoff for technical readers or future agents. | ### Rule If a file is used by a dashboard or parser, preserve its structured markers. Do not let a compression tool or rewrite mangle headings, statuses, usage fields, or checkboxes. ## Version Control And Backups ### TLDR Git is not a developer vanity tool. It is the undo system for agentic work. ### Why Git Matters Git is not just for professional developers. It is a safety net for agentic coding. Use Git before: - Large rewrites. - Dashboard edits. - Prompt refactors. - Package rebuilds. - Any change where "undo" would be painful. ### Beginner Git Loop ```text git status git add . git commit -m "Describe the safe checkpoint" ``` If the agent suggests an experiment, use a branch: ```text git checkout -b experiment-name ``` ### Simple Rule If an agent is about to change many files, make a checkpoint first. ## Testing And Verification ### TLDR The faster the agent creates work, the more important verification becomes. ### Verification Is Not Optional Agentic coding creates convincing output quickly. That makes verification more important, not less. Use three levels: 1. **Static checks:** syntax, lint, build, type checks. 2. **Rendered checks:** open the app/page and inspect what users see. 3. **Human checks:** taste, account flows, file pickers, payment settings, real devices. ### Record Gaps Honestly If the agent cannot test something, the right answer is not "done." The right answer is: ```text This part passed. This part could not be tested here. Add it to PENDING_VERIFICATION.md. ``` ### Good Done Criteria A feature is done when: - The code exists. - The expected behavior was tested. - The user-facing result was checked. - Known gaps are recorded. - Project memory was updated. ## Scope Control ### TLDR Every new idea needs a timing decision. Useful later is not the same as useful now. ### Why Scope Expands Agentic coding makes new ideas feel cheap. That is dangerous. The agent can build faster than the human can validate value. Common scope-expansion phrases: - "While we are at it..." - "Can we also..." - "Would it be hard to..." - "Maybe this should be Enterprise..." - "Can we optimize all features..." These are not bad questions. They just need a decision gate. ### The Decision Gate For every new idea, ask: 1. Does this improve the current release? 2. Does it make onboarding simpler or harder? 3. Is it valuable before users trust the core product? 4. Can it be tested now? 5. Is it v1, v2, parked, or out of scope? ## When To Build, Park, Or Delete An Idea ### TLDR Build what raises confidence now. Park what might matter later. Decline what violates the principles or distracts from the release. ### Build Now Build it now if it: - Fixes a blocker. - Raises release confidence. - Makes the product easier to understand. - Reduces verification debt. - Directly supports the current sprint goal. ### Park Park it if it: - Is probably useful later. - Requires infrastructure. - Adds support burden. - Depends on user demand that has not been proven. - Makes v1 harder to explain. ### Delete Or Decline Decline it if it: - Conflicts with the product principles. - Requires sensitive data without clear user benefit. - Duplicates what the platform already does well. - Adds complexity mostly because it is interesting. ## Working With Accounts, Payments, And Private Data ### TLDR Let the agent prepare and explain. The human should handle credentials, payments, permissions, and final account decisions. Agentic coders often hit a confusing boundary: the agent can help with setup, but the human owns private actions. ### Agent Can Do - Draft product descriptions. - Prepare setup checklists. - Explain which field means what. - Review public-facing copy. - Create local scripts or files. - Test public pages. ### Human Should Do - Enter payment details. - Approve account permissions. - Handle passwords and tokens. - Decide final pricing. - Publish paid products. - Confirm legal/privacy claims. ### Good Prompt ```text Prepare the setup steps and tell me exactly what I need to do myself. Do not ask for or handle private credentials. ``` ## From Activist Angle To Action ### TLDR Human-first AI should not end as a slogan. Every page, post, or lesson should give the reader a next action, a learning outcome, or a way to practice more agency. The DigitalQuill movement angle is not "AI is bad" or "use AI for everything." The useful claim is: people should own their work, spend compute intentionally, and build with tools that make them more capable. That means every activist or mission page should answer: 1. What can the reader do differently today? 2. What should they learn next? 3. What should they stop doing? 4. How does this protect their agency? 5. How does this help them build something real? ### Convert Values Into Actions | Value | Reader action | Learning outcome | |---|---|---| | Humans first | Ask the agent to explain tradeoffs before building. | The reader practices judgment instead of outsourcing it. | | Value over volume | Define one useful outcome before asking for more output. | The reader can tell progress from activity. | | Your work stays yours | Keep project memory in local Markdown files. | The reader understands file ownership and portability. | | Memory beats restarting | Maintain `PROJECT_STATE.md` and `DECISIONS.md`. | The reader can resume across sessions. | | Honest, not hyped | Record what was tested and what still needs proof. | The reader learns to ship with evidence. | ### Page-Level Action Pattern Every Learn or manifesto page should end with one of these: - **Try this now:** a 5-minute prompt or file exercise. - **Check your project:** a short diagnostic checklist. - **Learn next:** 2 or 3 free resources, not a giant list. - **Use the tool:** a clear Basic/Pro dashboard action. - **Reflect:** one question about whether the human ended up better off. ### Example Endings For a page about AI agents: ```text Try this now: create PROJECT_STATE.md and ask your agent to summarize the project from only that file. ``` For a page about value-based spending: ```text Check your project: list the last three things the agent did. Which one moved the project closer to a real user outcome? ``` For a page about local-first work: ```text Learn next: read the Markdown Guide, then make one decision log in plain text. ``` For a page about human-first AI: ```text Reflect: did the tool make you more capable, or did it only produce more output? ``` ## Free Learning Resources ### TLDR Use free resources that build ownership: Markdown, Git, web basics, prompt clarity, and safety. Avoid learning paths that make the platform more important than the project. These are free or free-to-read resources that fit the DigitalQuill principles: human-readable, practical, fundamentals-first, and useful without forcing a paid platform choice. | Resource | Use it for | Why it fits | |---|---|---| | [GitHub Skills](https://skills.github.com/) | Beginner GitHub workflows, issues, pull requests, Markdown. | Interactive, practical, and free. Good for learning version-control habits. | | [Pro Git book](https://git-scm.com/book/en/v2) | Understanding Git beyond button-clicking. | Free official Git book; helps users own their project history. | | [MDN Learn Web Development](https://developer.mozilla.org/en-US/docs/Learn_web_development) | HTML, CSS, JavaScript, web basics. | Strong beginner path from a trusted documentation source. | | [web.dev Learn](https://web.dev/learn) | Web fundamentals, performance, accessibility. | Free, practical, and useful for shipping better web experiences. | | [The Odin Project](https://www.theodinproject.com/) | Full web-development curriculum. | Free, project-based, and serious enough for people who want depth. | | [freeCodeCamp Learn](https://www.freecodecamp.org/learn/) | Practice-based coding fundamentals. | Free exercises and projects; useful for repetition. | | [Markdown Guide](https://www.markdownguide.org/getting-started/) | Learning Markdown files. | Helps users see `.md` files as friendly project memory, not scary code. | | [CommonMark](https://commonmark.org/) | Markdown rules and compatibility. | Useful when Markdown output needs to be predictable. | | [OpenAI Prompt Engineering Guide](https://platform.openai.com/docs/guides/prompt-engineering) | Prompting fundamentals for OpenAI users. | Official docs; useful for clearer instructions and task framing. | | [Anthropic Prompt Engineering](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview) | Prompting fundamentals for Claude users. | Official docs; reinforces clarity, examples, and context structure. | | [GitHub Copilot prompt engineering docs](https://docs.github.com/en/copilot/using-github-copilot/prompt-engineering-for-github-copilot) | Asking coding assistants better questions. | Practical examples for developer workflows. | | [OWASP Top 10 for LLM Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/) | Safety and security mindset. | Helps agentic coders think about risks, not only output. | ### Suggested Learning Order For a non-developer: 1. Markdown Guide. 2. GitHub Skills. 3. MDN Learn: HTML and CSS basics. 4. freeCodeCamp or The Odin Project. 5. Prompt engineering docs for the AI tool they actually use. For someone with an IT background: 1. Pro Git book. 2. GitHub Skills for pull requests and branching. 3. MDN or web.dev for frontend refreshers. 4. OWASP LLM Top 10 for risk awareness. 5. Prompt engineering docs for the current agent. ## Glossary ### TLDR These terms are the minimum vocabulary needed to work with agents without treating them like magic. ### Agent An AI assistant that can use tools, read files, make plans, and perform tasks. ### Context The information the agent can see during a session: chat messages, files, instructions, and tool output. ### Markdown Plain text with simple formatting markers. Good for project memory because humans and agents can both read it. ### Token A unit of text the AI reads or writes. More context usually costs more and can make the agent less focused. ### Verification Debt Work that appears complete but has not been tested enough to trust. ### Local-First A design principle where project files and memory stay on the user's machine unless the user explicitly chooses to share them. ### Parked An idea saved for later because it is not the right work now. ### V1 / V2 V1 is the smallest trustworthy release. V2 is what comes after real users prove what they need next. ## Checklists ### TLDR Checklists are how a smart beginner avoids relying on memory, confidence, or vibes. ### Before Starting A Session - [ ] Read `PROJECT_STATE.md`. - [ ] Read `TODO.md`. - [ ] Read `DECISIONS.md`. - [ ] Check `PENDING_VERIFICATION.md`. - [ ] Confirm the current sprint goal. - [ ] Confirm what files the agent may touch. ### Before A Risky Edit - [ ] Run `git status`. - [ ] Commit or back up current work. - [ ] Ask the agent to explain the risk. - [ ] Keep the edit scoped. - [ ] Avoid rewriting large files when a smaller patch will work. ### Before Calling Work Done - [ ] Static checks passed. - [ ] Rendered/user-facing behavior checked. - [ ] Real-folder or real-device checks done when needed. - [ ] Human-only responsibilities are listed. - [ ] TODO and pending verification are updated. - [ ] Iteration log is updated. ### Before Adding A New Feature - [ ] It supports the current goal. - [ ] It is not just interesting. - [ ] It does not make onboarding harder. - [ ] It can be tested. - [ ] It is not a V2 idea pretending to be V1. ## Final Rule Agentic coding works best when the human stays in charge of meaning and the files stay in charge of memory. The agent can help build the product. The workflow keeps the product from becoming a pile of output.